home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 21 / Cream of the Crop 21 (Terry Blount) (October 1996).iso / os2 / lynxos26.zip / docs / rfc-mail.txt < prev   
Text File  |  1994-03-23  |  32KB  |  742 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.             Network Working Group               N. Borenstein, Bellcore
  8.             Internet Draft                                  March, 1993
  9.  
  10.                         A User Agent Configuration Mechanism
  11.  
  12.                        For Multimedia Mail Format Information
  13.  
  14.  
  15.           Status of This Memo
  16.  
  17.             This  RFC  specifies  an  informational  protocol  for   the
  18.             Internet  community, and requests discussion and suggestions
  19.             for improvements.  Distribution of this memo is unlimited.
  20.  
  21.           Abstract
  22.  
  23.             This memo suggests a  file  format  to  be  used  to  inform
  24.             multiple   mail   reading  user  agent  programs  about  the
  25.             locally-installed facilities for handling  mail  in  various
  26.             formats.  The  mechanism is explicitly designed to work with
  27.             mail systems based Internet mail as defined  by  RFC's  821,
  28.             822,  934,  1049,  1113,  and the Multipurpose Internet Mail
  29.             Extensions, known as MIME.  However, with some extensions it
  30.             could  probably be made to work for X.400-based mail systems
  31.             as well.  The format and mechanism are proposed in a  manner
  32.             that  is  generally  operating-system independent.  However,
  33.             certain  implementation  details  will  inevitably   reflect
  34.             operating  system differences, some of which will have to be
  35.             handled in a uniform manner for each operating system.  This
  36.             memo  makes  such  situations explicit, and, in an appendix,
  37.             suggests  a  standard  behavior  under  the  UNIX  operating
  38.             system.
  39.  
  40.           Introduction
  41.  
  42.             The electronic mail world is in the midst  of  a  transition
  43.             from  single-part  text-only mail to multi-part, multi-media
  44.             mail.  In support of this transition, various extensions  to
  45.             RFC  821  and  RFC  822  have  been proposed and/or adopted,
  46.             notably including  MIME  [RFC-1341].  Various  parties  have
  47.             demonstrated  extremely  high-functionality multimedia mail,
  48.             but the problem of mail interchange between  different  user
  49.             agents has been severe.  In general, only text messages have
  50.             been shared between user agents  that  were  not  explicitly
  51.             designed   to   work   together.   This  limitation  is  not
  52.             compatible with a smooth transition to  a  multi-media  mail
  53.  
  54.  
  55.  
  56.             Borenstein         DRAFT - expires 8/1/93           [Page 1]
  57.  
  58.  
  59.  
  60.  
  61.             MAILCAP        Multimedia Mail Configuration      March 1993
  62.  
  63.  
  64.             world.
  65.  
  66.             One approach to this transition is to modify diverse sets of
  67.             mail  reading user agents so that, when they need to display
  68.             mail of an  unfamiliar  (non-text)  type,  they  consult  an
  69.             external  file  for information on how to display that file.
  70.             That file might say, for example, that if  the  content-type
  71.             of  a  message  is "foo" it can be displayed to the user via
  72.             the "displayfoo" program.
  73.  
  74.             This approach means that, with a  one-time  modification,  a
  75.             wide  variety  of  mail  reading  programs  can be given the
  76.             ability to display a  wide  variety  of  types  of  message.
  77.             Moreover,  extending  the  set of media types supported at a
  78.             site becomes a simple matter  of  installing  a  binary  and
  79.             adding  a  single  line to a configuration file.  Crucial to
  80.             this scheme, however, is that all of the user  agents  agree
  81.             on  a common representation and source for the configuration
  82.             file.  This memo proposes such a common representation.
  83.  
  84.           Location of Configuration Information
  85.  
  86.             Each  user  agent  must  clearly  obtain  the  configuration
  87.             information  from a common location, if the same information
  88.             is to be  used  to  configure  all  user  agents.   However,
  89.             individual  users  should  be  able to override or augment a
  90.             site's configuration.  The configuration information  should
  91.             therefore  be  obtained  from a designated set of locations.
  92.             The overall  configuration  will  be  obtained  through  the
  93.             virtual  concatenation  of  several individual configuration
  94.             files known as mailcap files.  The configuration information
  95.             will  be obtained from the FIRST matching entry in a mailcap
  96.             file, where "matching" depends on both a  matching  content-
  97.             type   specification,   an   entry   containing   sufficient
  98.             information for the purposes of the  application  doing  the
  99.             searching, and the success of any test in the "test=" field,
  100.             if present.
  101.  
  102.             The precise location of  the  mailcap  files  is  operating-
  103.             system dependent.  A standard location for UNIX is specified
  104.             in Appendix A.
  105.  
  106.           Overall Format of a Mailcap File
  107.  
  108.             Each mailcap file consists of a set of entries that describe
  109.             the  proper  handling  of  one media type at the local site.
  110.  
  111.  
  112.  
  113.             Borenstein         DRAFT - expires 8/1/93           [Page 2]
  114.  
  115.  
  116.  
  117.  
  118.             MAILCAP        Multimedia Mail Configuration      March 1993
  119.  
  120.  
  121.             For example, one line might tell how to display a message in
  122.             Group III fax format.  A mailcap file consists of a sequence
  123.             of such individual entries, separated by newlines (according
  124.             to  the operating system's newline conventions). Blank lines
  125.             and lines that start with the "#" character (ASCII  35)  are
  126.             considered  comments,  and are ignored.  Long entries may be
  127.             continued on multiple lines if each non-terminal  line  ends
  128.             with  a  backslash  character ('\', ASCII 92), in which case
  129.             the multiple lines are to be treated  as  a  single  mailcap
  130.             entry.   Note that for such "continued" lines, the backslash
  131.             must be the last character on the line to be continued.
  132.  
  133.             Thus the overall format of a mailcap file is given,  in  the
  134.             modified BNF of RFC 822, as:
  135.  
  136.                  Mailcap-File = *Mailcap-Line
  137.  
  138.                  Mailcap-Line = Comment / Mailcap-Entry
  139.  
  140.                  Comment = NEWLINE  /  "#" *CHAR NEWLINE
  141.  
  142.                  NEWLINE = <newline as defined by OS convention>
  143.  
  144.             Note that the above specification implies that comments must
  145.             appear  on  lines all to themselves, with a "#" character as
  146.             the first character on each comment line.
  147.  
  148.           Format of a Mailcap Entry
  149.  
  150.             Each mailcap entry consists of a number of fields, separated
  151.             by semi-colons.  The first two fields are required, and must
  152.             occur in the specified  order.   The  remaining  fields  are
  153.             optional, and may appear in any order.
  154.  
  155.             The first field is the  content-type,  which  indicates  the
  156.             type of data this mailcap entry describes how to handle.  It
  157.             is to be matched against the type/subtype  specification  in
  158.             the "Content-Type" header field of an Internet mail message.
  159.             If the subtype is specified as "*", it is intended to  match
  160.             all subtypes of the named content-type.
  161.  
  162.             The second field, view-command, is a  specification  of  how
  163.             the  message  or  body part can be viewed at the local site.
  164.             Although the syntax of this field is  fully  specified,  the
  165.             semantics  of  program  execution  are  necessarily somewhat
  166.             operating system dependent.  UNIX  semantics  are  given  in
  167.  
  168.  
  169.  
  170.             Borenstein         DRAFT - expires 8/1/93           [Page 3]
  171.  
  172.  
  173.  
  174.  
  175.             MAILCAP        Multimedia Mail Configuration      March 1993
  176.  
  177.  
  178.             Appendix A.
  179.  
  180.             The optional fields, which may be given in any order, are as
  181.             follows:
  182.  
  183.             -- The "compose" field may be used to specify a program tha